A TPM is a “Trusted Platform Module” that can be used to implement a wide variety of security functions in a computational platform. The specifications currently created by the Trusted Computing Group (TCG) however limit the ability to create new identities with which the TPM may communicate to the owners of a “TPM owner authorization secret”. The owners of this secret however may also shut down the TPM permanently. If critical system services depend on the TPM this would be disastrous and may cause a risk for a device to be eligible for warranty, if a piece of un-trusted software could do this.
The TCG defined TPM 1.2 which defines the concepts of attestation identities and secure storage areas. At the root of the hierarchy is a “secure storage root”. This is an area of secure storage that can only be accessed by parties that have access to the storage root key authorization secret. Secure storage is implemented using asymmetric storage keys that are wrapped by a parent storage key. Each storage key (except the root) has exactly one parent storage key and a single store key can have a multitude of child storage keys. A storage key defines a single secure storage area. The areas of secure storage therefore constitute a tree-like structure, with the “secure storage root” as the root of the tree. Each area of secure storage can have its own “authorization secret” that is required to be able to access the area of secure storage. Loading a secure storage key into a TPM also requires knowledge of the parent storage key authorization secret (except for the root storage key). Additionally the secure storage area can be restricted to be available to a certain defined state of the platform.
Attestation identities however are all linked directly to the secure storage root and additionally creation of these identities requires approval from the owner of the TPM.
Authorization
All objects inside a TPM can have an authorization secret associated with them. Knowledge of this authorization secret is then required for using this object. Additionally knowledge of a parent object's authorization secret is often required for creating an object.
The TCG TPM 1.2 defines three authorization protocols that can be used: OI-AP, OS-AP, and DSAP.
OI-AP (Object Independent Authorization Protocol) is based on the TPM_OIAP command. This command creates a handle inside a TPM and associates a nonce with it. At this point no secrets are exchanged. Use of this handle to authorize commands requires that each command is separately authorized using the authorization key of the object the command is manipulating. This means that the handle cannot be forwarded to another party for later use.
OS-AP (Object Specific Authorization Protocol) is based on the TPM_OSAP command. This command creates a handle bound to a single object inside a TPM and creates a shared secret from it. The shared secret is computed as HMAC_SHA1{object authz secret}(server nonce∥client nonce). The handle can then be passed to another party who then will not need the actual object authorization key to use authorization. The generated session secret can once be used to encrypt an input parameter. This encryption is generally performed using an XOR with SHA1(shared secret∥some nonce). Using this encryption voids the OS-AP session. Additionally the shared secret can be (with a similar method) be used to encrypt the nonces passed back and forth in the protocol.
DSAP (Delegation Specific Authorization Protocol) is based on the TPM_DSAP command. This command creates a handle bound to a single delegation authorizing. This protocol also creates a shared secret specific to the session similar to the OS-AP protocol.
Delegation
Delegation is performed using the following commands:
Delegate Manage (TPM_Delegate_Manage);
Key Creation (TPM_Delegate_CreateKeyDelegation);
Creation of Owner (TPM_Delegate_CreateOwnerDelegation);
Owner loading (TPM_Delegate_LoadOwnerDelegation);
Table reading (TPM_Delegate_ReadTable);
Verification updating (TPM_Delegate_UpdateVerification); and
Delegation verification (TPM_Delegate_VerifyDelegation).
The TPM Owner is an entity with a single “super user” privilege to control TPM operation. Thus if any aspect of a TPM requires management, the TPM Owner must perform that task himself or reveal his privilege information to another entity. This other entity thereby obtains the privilege to operate all TPM controls, not just those intended by the Owner. Therefore the Owner often must have greater trust in the other entity than is strictly necessary to perform an arbitrary task.
This delegation model addresses this issue by allowing delegation of individual TPM Owner privileges (the right to use individual Owner authorized TPM commands) to individual entities, which may be trusted processes.
Consumer user does not need to enter or remember a TPM Owner password. This is an ease of use and security issue. Not remembering the password may lead to bad security practices, increased tech support calls and lost data.
Role based administration and separation of duty. It should be possible to delegate just enough Owner privileges to perform some administration task or carry out some duty, without delegating all Owner privileges.
TPM should support multiple trusted processes. When a platform has the ability to load and execute multiple trusted processes then the TPM should be able to participate in the protection of secrets and proper management of the processes and their secrets. In fact, the TPM most likely is the root of storage for these values. The TPM should enable the proper management, protection and distribution of values held for the various trusted processes that reside on the same platform.
Trusted processes may require restrictions. A fundamental security tenet is the principle of least privilege, that is, to limit process functionality to only the functions necessary to accomplish the task. This delegation model provides a building block that allows a system designer to create single purpose processes and then ensure that the process only has access to the functions that it requires to complete the task.
There is no desire to remove the current TPM Owner and the protocols that authorize and manage the TPM Owner. The capabilities are a delegation of TPM Owner responsibilities. The delegation allows the TPM Owner to delegate some or all of the actions that a TPM Owner can perform. The TPM Owner has complete control as to when and if the capability delegation is in use.
Revoking a delegation, does not affect other delegations—The TPM Owner may, at any time, determine that a delegation is no longer appropriate. The TPM Owner needs to be able to ensure the revocation of all delegations in the same family. The TPM Owner also wants to ensure that revocation done in one family does not affect any other family of delegations.
External delegations need authorization and assurance of revocation. When a delegation is held external to the TPM, the TPM must ensure authorization of the delegation when loading the delegation. Upon revocation of a family or other family changes the TPM must ensure that prior valid delegations are not successfully loaded.
There is, however, one nuance in this delegation mechanism. The creation of owner command delegations cannot be delegated in a secure manner. This is because delegations of owner commands are done using the creation of owner command (TPM_Delegate_CreateOwnerDelegation) and the actual delegated command is passed as an input parameter. Delegating a right to use the creation of owner command (TPM_Delegate_CreateOwnerDelegation) is essentially equivalent to giving that party the TPM owner secret. This is not desirable, as if one possesses the TPM owner secret one may be able to permanently disable the TPM in question. This is especially disastrous in the case of embedded systems that are under warranty.
These mechanisms allow essentially delegating access to the make identity command (TPM_MakeIdentity) and the activate identity command (TPM_ActivateIdentity) to other parties. However, there is no secure way to dynamically at runtime let arbitrary parties create TPM identities without resorting to use of the TPM owner secret.
The TCG TPM version 1.2 allows sealing access to data to a certain “trust-state” of the platform. The trust-state is measured using a stack of so-called “Platform Configuration Registers” that contain a hash (or hash-chain) of software loaded into the software stack of the host system. In a PC, for example, the lowest register of the stack could be a measurement of the BIOS, the second lowest register could be a measurement of the boot-loader of the OS and so forth.
If some object has been sealed to a certain trust-state then that data is available only when the system is in that trust-state. This is performed e.g. by encrypting an object in such a manner that only the TPM can decrypt the object and verify its integrity. Inside this object is then stored decryption and verification keys and the required trust-state for the actual sealed data.
Sealing and unsealing an object requires access to the authorization data of the parent storage key object.